feat(stream): add an activity heatmap that drives the date filter - #2839

The date range added with the search filters was hidden behind a dropdown, so
choosing one meant guessing which period had anything in it. A "Heatmap" entry
in the app navigation now opens an overview drawing a year of activity as a
calendar grid, and picking cells chooses a period: click a day, or shift-click
a second one for a span. Clicking the only selected day deselects it, so the
same cell toggles rather than trapping the reader in a one day view. "Show
these activities" then opens the stream restricted to that period, carrying
the range as query parameters because the stream already restores its filters
from the URL, which also makes the result linkable.

It is a view of its own rather than a band above the feed: a chart that is
permanently in the way of the list people came to read is a distraction, and
this one answers a different question from the stream it feeds.

Counts come from a new endpoint,
`GET /api/v2/activity/{filter}/histogram`, returning activities per calendar
day.

It shares its WHERE building with the stream query. That refactor is the
point rather than tidiness: a histogram whose columns count rows the feed
below it does not list is worse than no histogram, and the filter, type, app
and favourites conditions are far too involved to keep correct in two
places. The endpoint honours the active search and account for the same
reason, but deliberately takes no from/to, because the histogram is the
control a range is picked *with* and has to keep showing the days outside
the selection.

Days are bucketed in the account's timezone rather than UTC, so an activity
at 01:00 local time belongs to that local day. A real DateTimeZone is passed
rather than a fixed offset, which is what keeps a window spanning a DST
change correct. Bucketing runs in PHP: grouping by day needs integer
division or a modulo, neither expressible through IQueryBuilder, and a raw
expression would need four dialects for the databases this app tests
against. The query stays cheap regardless — one column, one affecteduser, a
timestamp range, which is the existing activity_user_time index.

Hitting the row guard is reported as `partial_before` instead of hidden, so
the affected days are marked rather than drawn as measured but understated
values.

On the colour: the ramp is the theme's own accent mixed into the surface at
45/63/81/100% in OKLab, so it follows a custom primary colour, and because
--color-primary-element is contrast-adjusted per theme by the server the
scale runs light-to-dark on white and dark-to-light on the dark surface —
the anchor flip a sequential scale needs, without a second palette. The four
steps were checked against both Nextcloud surfaces: monotone OKLCH
lightness, adjacent gaps >= 0.09, single hue. The lightest step was raised
until it clears 2:1 against the surface, because the palest tint is a day
with *one* activity and had been indistinguishable from an empty one; "no
activity" is a neutral instead, which reads as nothing rather than as a
small value.

Days with no activity are omitted from the payload rather than sent as
zeroes, so its size tracks real activity instead of the window length, and
the client fills the gaps.

The grid is a real table with a caption and row headers, every cell is a
button carrying the date and exact count as its accessible name, and focus
shows the same readout as hover — so no value depends on either hovering or
reading a colour. One cell is exposed to Tab at a time, with arrow keys
moving a day vertically and a week horizontally, and Home/End jumping to the
ends of the window. Selection is drawn as a ring, never a fill, since the
fill is spoken for by the value and repainting it would misstate the count.

Rendered in both themes and inspected before shipping, which is what caught
the window being too short: at 26 weeks the grid filled under half the column
and left the legend stranded, so it defaults to 52.

Signed-off-by: Frank Karlitschek <karlitschek@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

php-cs-fixer wants a multi-line @return description aligned under the
description column, which for this signature meant indenting the wrap to
column 68. The description belongs in the docblock body instead, so the
@return line stays a single type and there is nothing to align.

Reproduced and verified with php-cs-fixer 3.95.15, the version CI pins:
1 of 97 files before, 0 of 97 after.

Signed-off-by: Frank Karlitschek <karlitschek@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>